Implementing a design system in 3 major steps in a company?
I don’t think we need to talk about the benefits of a Design system in 2020, this is not the subject here. This story is about the use case of the process of integrating a design system in a french company of 200 peoples.
But why a design system ?
The design system is an internal product of a company that allows to design and develop more efficiently. Based on the analogy of legos, it is composed of blocks that are the interfaces’ foundations. The blocks are hosted in a component’s library. A documentation is necessary to inform stakeholders about design guidelines and the best practices regarding component usage according to end-users’ uses. It is obvious that the first benefit of a design system enables teams to connect, share and accumulate their inputs, as co-construction improves the quality of the product and harmonize interfaces. The second and not the least benefit is the possibility to make mistakes. A component developed within the system is much more easily changeable, because by definition the impact of the change is systemic, that mean by upgrading a component, you update all the places where you use it. Moreover, it will facilitate the work of global harmonization of your interfaces because by setting up a design system, we naturally put in place guidelines. Finally when a new designer joins a company it will be much easier to onboard him or her… Again, it’s not the subject, you can find a lot of articles about its benefits on medium. Let’s get into the subject.
How to implement a design system ?
In order to illustrate this I will take the case of Wynd Thematic Group company. A good understanding of the organizational context of the company is important to figure out the necessity to build a Design system in such an environment. The Wynd platform has been designed to meet the challenges of retailer’s digital transformation. It is natively omnichannel and allows you to cover all your customer journey by developing several products. Wynd’s structure is built on Scrum Spotify model. Indeed, each product is developed in a dedicated team, called “Squad” with 1 PO, 1 QA, 4/6 developers, 1 UX and 1 UI.
As designers and developers are isolated in their own Squad, the Design System enables teams to connect, share and accumulate their inputs through production cycles. The Design System we are building is currently managed by two teams (web and mobile). These teams are composed by one designer and one developer who supervise and follow the progression of the system, they are the voice of the system.
These steps result of my experience in Wynd, they are presented chronologically.
First step : Architecture 🏗️
We first designed the architecture of the system by putting a common library in the center of our inputs sharing. This common library includes token assets related to the brand’s identity (colors, elevations, icons, containers etc.). Then we connected to it 3 specific libraries related to particular digital languages exploited by Wynd (IOS, React and Android).
We have delimited the libraries according to the different types of languages used in the company in order to facilitate the integration with the developers because the guidelines are not exactly the same according to the devices. On the other hand, each squad is able to build its own components without using the design system to address specific projects.
At the same time, we have organized numerous workshops to identify graphic disparities between Wynd’s products in order to harmonize the experience and share the right components. For example, from one product to another, there were not the same set of colours used. It was due to an isolated design in its own squad.
Second step : Evangelisation 📢
Achieving a Design System means getting a consensual approval into the team. By including everyone into this project all the way of its conception, the final structure offers a win-win proposal between each part and gets its success. We also have done internal presentations to demonstrate the working method and processes.
The Design System currently doesn’t have a name, but I think it’s a very good way to communicate internally because it allows us to make it known and to be recognized.The fact we have the term “Design” can make a confusion for the company stackholders, they think a Design System is only for designers.
The documentation is also a very important tools to share the best practises, graphic identity and nomenclature for marketing, developers and business developers. For this we use the french tool “Zeroheight”.
Third step : Framework & rituel 🏟️
We start to really find the benefits of the system and gain in terms of productivity but not enough.We still take too much time sharing and mutualizing subjects. So we start thinking about the process of creation. I think this is an important issue, very present in many companies and worth working on.
In order to avoid duplicated subjects, lost work or to redo it is necessary to find a way to coordinate all this in a simple and clear way. We have to create our own framework. First of all, we dedicate one hour per week to a round table discussion to share, exchange and review components specifications of the design system with all designers and the lead developer. Moreover, in order to optimize our tasks we do a workshop to define the steps of creation in Kanban mode with the definitions of done at each step. Here is the result that I share with you. It goes without saying that it can be modeled according to your needs.
The journey of creation of a component begins with the proposal until the integration in the dev library, through the documentation.
For this we use Notion that allows you to follow the tasks by moving them inside the Kanban. Historically, developers use Jira cards. Being on two different tools, this implies that the system designer has to duplicate the ticket finalized by the designers on the Jira board.
According to me, it’s a pain point to use two different tools because it makes it harder to keep track of the tasks. However I think Jira would be a good solution for designers too because it would bring up KPIs on productivity and time delivered to design a component. Indeed it would allow to have a good estimation of the cost for the company to develop a Design System. Currently we only have the metrics about the number of component used on products :
The difference between the number of developed screen and design screen is because sometimes by designing we need to duplicate screen in order to describe a flow for stockholders.
I hope you enjoyed the reading !
It’s all about a team works and it’s a good opportunity to say thank you to all for the good vibes : Alisa, Antoine, Anouk, Arnaud, Blandine, Gabriel A, Gabriel G, Jami, Loic, Lou, Mathieu, Maxime, Olga, Rachel, Raphael, Romain, Sacha, Thibault.
Special thanks to Romain Malengrez to review this post.
